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Foreword 



This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN) and originally published as ETSI TS 183 007 
[14]. It was transferred to the 3rd Generation Partnership Project (3GPP) in January 2008. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage three (protocol description) of the Originating Identification Presentation 
(OIP) supplementary service and the Originating Identification Restriction (OIR) supplementary services, based on 
stage one and two of the ISDN CLIP [4] and CLIR [5] supplementary service. It provides the protocol details in the IP 
Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session 
Description Protocol (SDP). 

NOTE: It can be noted that the behaviour described in this the present document does not take into account other 
behaviours that is specified in other applications and care needs to be taken when designing the filters etc. 
when two or more applications are involved in a session. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 23.002: "Network architecture". 

[2] 3GPP TS 23.228: "IP multimedia subsystem; Stage 2". 

[3] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP". 

[4] ETSI EN 300 089: "Integrated Services Digital Network (ISDN); Calling Line Identification 

Presentation (CLIP) supplementary service; Service description". 

[5] ETSI EN 300 090: "Integrated Services Digital Network (ISDN); Calling Line Identification 

Restriction (CLIR) supplementary service; Service description". 

[6] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)". 

[7] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted 

Identity within Trusted Networks". 

[8] IETF RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax". 

[9] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[ 1 0] IETF RFC 326 1 :" SIP: Session Initiation Protocol" . 

[11] Void 

[12] ITU-T Recommendation 1.210: "Principles of telecommunication services supported by an ISDN 

and the means to describe them ". 

[13] 3GPP TS 24.623: "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 

over the Ut interface for Manipulating Supplementary Services". 

[14] ETSI TS 183 007 VI. 3.0: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Originating Identification 
Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification" 

[15] 3GPP TS 24.238: "Session Initiation Protocol (SIP) based user configuration; stage 3" 
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[16] IETF RFC 4825: "The Extensible Markup Language (XML) Configuration Access Protocol 

(XCAP)". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Call Session Control Function (CSCF): See 3GPP TS 23.002 [1]. 

dialog: See IETF RFC 3261 [10]. 

header: See IETF RFC 3261 [10]. 

header field: See IETF RFC 3261 [10]. 

identity information: all the information identifying a user, including trusted (network generated) and/or untrusted 
(user generated) addresses 

NOTE: Identity information takes the form of either a SIP URl (see IETF RFC 2396 [8]) or a "tel" URI 
(see IETF RFC 3966 [9]) . 

incoming initial request: all requests intended to initiate either a dialog or a standalone transaction terminated by the 
served user 

Interconnection Border Control Function (IBCF): See 3GPP TS 23.228 [2]. 

Media Gateway Control Function (MGCF): See 3GPP TS 23.002 [1]. 

originating UE: sender of a SIP request intended to initiate either a dialog (e.g. INVITE, SUBSCRIBE), or a 
standalone transaction 

EXAMPLE: OPTIONS, MESSAGE. 

outgoing (communication): communication outgoing from the user side of the interface 

outgoing initial request: all requests intended to initiate either a dialog or a standalone transaction received from the 
served user 

proxy: See IETF RFC 3261 [10]. 

Proxy-CSCF (P-CSCF): See 3GPP TS 23.228 [2]. 

public user identity: See 3GPP TS 23.228 [2]. 

request: See IETF RFC 3261 [10]. 

response: See IETF RFC 3261 [10]. 

Serving-CSCF (S-CSCF): See 3GPP TS 23.228 [2]. 

session: See IETF RFC 3261 [10]. 

standalone transaction: SIP transaction that is not part of a dialog and does not initiate a dialog 

NOTE: An OPTIONS or a MESSAGE request sent outside of a SIP dialog would be considered to be part of a 
standalone transaction. 

supplementary service: See ITU-T Recommendation 1.210 [12], clause 2.4. 

tag: See IETF RFC 3261 [10]. 
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terminating UE: recipient of a SIP request intended either to initiate a dialog or to initiate either a dialog or a 
standalone transaction 

trusted identity information: network generated user public identity information 

(SIP) transaction: See IETF RFC 3261 [10]. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

CCBS Completion of Communication to Busy Subscriber 

CDIV Communication Diversion 

CLIP Calling Line Identification Presentation 

CLIR Calling Line Identification Restriction 

CSCF Call Session Control Function 

CW Communication Waiting 

HOLD communication Hold 

IBCF Interconnection Border Control Function 

ICB Incoming Communication Barring 

IFC Initial Filter Criteria 

IM IP Multimedia 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Data Network 

MCID Malicious Communication IDentification 

MGCF Media Gateway Control Function 

NGN Next Generation Network 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

P-CSCF Proxy-CSCF 

PSTN Public Switched Telephone Network 

S-CSCF Serving-CSCF 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UE User Equipment 

URI Universal Resource Identifier 



Originating Identification Presentation (OIP) and 
Originating Identification Restriction (OIR) 



4.1 



Introduction 



The Originating Identification Presentation (OIP) service provides the terminating user with the possibility of receiving 
identity information in order to identify the originating user. 

The Originating Identification Restriction (OIR) service enables the originating user to prevent presentation of its 
identity information to the terminating user. 

4.2 Description 
4.2.1 General description 

The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network-provided) identity 
information in order to identify the originating user. 
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In addition to the trusted identity information, the identity information from the originating user can include identity 
information generated by the originating user and in general transparently transported by the network. In the particular 
case where the "no screening" special arrangement does not apply, the originating network shall verify the content of 
this user generated identity information. The terminating network cannot be responsible for the content of this user 
generated identity information. 

The OIR service is a service offered to the originating user. It restricts presentation of the originating user's identity 
information to the terminating user. 

When the OIR service is applicable and activated, the originating network provides the destination network with the 
indication that the originating user's identity information is not allowed to be presented to the terminating user. In this 
case, no originating user's identity information shall be included in the requests sent to the terminating user. The 
presentation restriction function shall not influence the forwarding of the originating user's identity information within 
the network as part of the supplementary service procedures. 

4.3 Operational requirements 
4.3.1 Provision/withdrawal 

4.3.1.1 01 P Provision/withdrawal 

The OIP service may be provided after prior arrangement with the service provider or be generally available. 

The OIP service shall be withdrawn at the subscriber's request or for administrative reasons. 

As a general operator policy a special arrangement may exist on a per subscriber basis or on a general behaviour basis 
whereby the originating user's identity information intended to be transparently transported by the network is not 
screened by the network. 

4.3.1.2 OIR Provision/withdrawal 

The OIR service, temporary mode, may be provided on a subscription basis or may be generally available. 

The OIR service, permanent mode, shall be provided on a subscription basis. 

As a network option, the OIR service can be offered with several subscription options. A network providing the OIR 
service shall support temporary mode at a minimum. Subscription options are summarized in table 1 . 

Table 1 : OIR Subscription options 



Subscription option values 


Values 


Mode 


- permanent mode (active for all requests) 

- temporary mode (specified by the UE per the initial 
outgoing request) 


Temporary mode default 


- presentation restricted 

- presentation not restricted 


Restriction 


- restrict the asserted identity 

- restrict all private information appearing in headers 



4.3.2 Requirements on the originating network side 

As part of the basic communication procedures specified in 3GPP TS 24.229 [3], the following requirements apply at 
the originating network side in support of the OIP service and the OIR service. Unless noted otherwise, these 
requirements are meant to apply to all requests meant to initiate either a dialog or a standalone transaction. These 
procedures apply regardless of whether the originating or terminating parties subscribe to the OIP service or the OIR 
service: 

1 The originating UE can insert two forms of identity information that correspond to the following two purposes: 
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As a suggestion to the network as to what public user identity the network should be included in the request 
as network asserted identity information. 

As a UE-provided identity to be transparently transported by the network. 

2 In the case where no identity information is provided by the originating UE for the purpose of suggesting a 
network-provided identity, the network shall include identity information based on the default public user 
identity associated with the originating UE. 

3 In the case where identity information is provided by the originating UE for the purpose of suggesting a 
network-provided identity, the network shall attempt to match the information provided with the set of registered 
public identities of the originating UE. If a match is found, the network shall include an identity based on the 
information provided by the originating UE. 

As a network option, if the "no screening" special arrangement does not exist with the originating UE, the network may 
attempt to match the UE-provided identity information with the set of registered public identities of the originating user. 
If a match is not found, the network shall replace the UE-provided identity with one that includes the default public user 
identity. 

The UE can include an indication that it wishes to have the presentation of its identity information to be restricted. 
The following cases exist: 

If the originating user has subscribed to the OIR service in the permanent mode, then the network shall invoke 
the OIR service for each outgoing request. 

If the originating user has subscribed to the OIR service in the temporary mode with default value "presentation 
restricted", then the network shall invoke the OIR service for each outgoing request unless the default value is 
overridden by subscriber request at the time of outgoing request. 

If the originating user has subscribed to the OIR service in the temporary mode with default value "presentation 
not restricted", then the network shall only invoke the OIR service if requested by the subscriber at the time of 
outgoing initial request. 

If the OIR service is not invoked, the network-provided identity shall be considered to be presentation allowed. 

NOTE 1 A: For the network to invoke the service, the S-CSCF will forward an initial request towards the AS that 
hosts the OIR service. This requires an initial filter criterion to be setup for the user who is subscribed to 
the service. Annex B provides an example of an initial filter criterion that can be applied for the OIR 

service. 

As an originating network option, if the originating user invokes the OIR service for a particular request, the originating 
network may prevent any UE-provided identification information (in addition to the trusted identity information) from 
being displayed to the terminating user. 

NOTE 1 : As an informative description, for OIP/OIR this means the following procedures are expected to be 

provided by the P-CSCF regardless of whether the originating user does or does not subscribe to the OIP 
service or OIR service. When the P-CSCF receives an initial request for a dialog or a request for a 
standalone transaction, and the request contains a P-Preferred-Identity header field that matches one of 
the registered public user identities, the P-CSCF is expected to identify the initiator of the request by that 
public user identity. In particular, the P-CSCF is expected to include a P-Asserted-Identity header field 
set to that public user identity. When the P-CSCF receives an initial request for a dialog or a request for a 
standalone transaction, and the request contains as P-Preferred-Identity header field that does not match 
one of the registered public user identities, or does not contain a P-Preferred-Identity header field, the 
P-CSCF is expected to identify the initiator of the request by a default public user identity. In particular, 
the P-CSCF is expected to include a P-Asserted-Identity header field set to the default public user 
identity. If there is more then one default public user identity available, the P-CSCF is expected to 
randomly select one of them. 

NOTE 2: In the case where the S-CSCF has knowledge of an associated tel-URI for a SIP URI contained in the 
P-Asserted-Identity header field received in the request, the S-CSCF adds a second P-Asserted-Identity 
header field containing this tel-URI. 

NOTE 3: For the S-CSCF to forward an initial request towards the AS that hosts the OIR service, an initial filter 
criterion is to be setup for the user who is subscribed to the service. Annex B provides an example of an 
initial filter criterion that that can be applied for the OIR service. 
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NOTE 4: It is assumed that the IBCF is responsible for stripping the P-Asserted-Identity from the SIP header when 
interworking with untrusted networks. 

4.3.3 Requirements on the terminating network side 

For terminating users that subscribe to the OIF service, and if network provided identity information about the 
originator is available, and if presentation is allowed, the network shall include that information in the requests sent to 
the UE. 

If the presentation of the public user identity is restricted, then the terminating UE shall receive an indication that the 
public user identity was not sent because of restriction. 

If the public user identity is not available at the terminating network (for reasons such as interworking), then the 
network shall indicate to the terminating user that the public user identity was not included for reasons other than that 
the originating user invoked the OIR service. 

For terminating users that do not subscribe to the OIF service, the network shall not send the network provided identity 
information about the originator in the requests sent to the UE, even if that information is available, and if presentation 
is allowed. Additionally, the network may prevent the transmission of any UE-provided identity information. 

NOTE 1: The CSCF applies any privacy required by RFC 3325 [7] to the F-Asserted-Identity. In particular, if the 
Frivacy header field is included and set to "id", the S-CSCF removes any F-Asserted-Identity header 
fields from the request. 

NOTE 2: The priv-value "id" in the Frivacy header is not expected be removed when removing any F-Asserted- 
Identity header as described in 3GFF TS 24.229 [3] subclause 5.4.3.3. 

If the request contains the Frivacy header field "header" or "user" the S-CSCF forwards the request to the AS. 

NOTE 3: For the S-CSCF to forward an initial request or standalone request to an AS, an initial filter criterion is to 
be setup for the user who is subscribed to the service. Annex B provides an example of an initial filter 
criterion that that can be applied for the OIF service. 

NOTE 4: When removing the F-Asserted-identity any following service in the chain could be affected. Therefore 
service based on the originating identity (such as ICB and ACR), are expected to precede the OIF service 
in the chain. 

NOTE 5: It is assumed that the IBCF is responsible for stripping the F-Asserted-Identity from the SIF header when 
interworking with untrusted networks. 



4.4 Syntax requirements 



The syntax for the relevant header fields in the SIF requests are normatively described in 3GFF TS 24.229 [3]. The 
relevant headers are: 

The F-Freferred-Identity header field, which shall conform to the specifications in IETF RFC 3325 [7] and 
IETF RFC 3966 [9]. 

The F-Asserted-Identity header field, which shall conform to the specifications in IETF RFC 3325 [7] and 
IETF RFC 3966 [9]. 

The Frivacy header field, which shall conform to the specifications in IETF RFC 3323 [6] and 
IETF RFC 3325 [7]. 

The From header field, which shall conform to the specifications in IETF RFC 3261 [10] and 
IETF RFC 3966 [9]. 
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4.5 Signalling procedures 

4.5.0 General 

Configuration of supplementary services by the user should: 

take place over the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [13]; or 
- use SIP based user configuration as described in 3GPP TS 24.238 [15]; 

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the 

operator are outside the scope of the present document, but are not precluded. 

The enhancements to the XML schema for use over the Ut interface are described in subclause 4.10. 

4.5.1 Activation/deactivation 

The OIP service is activated at provisioning and deactivated at withdrawal. 
The OIR service is activated at provisioning and deactivated at withdrawal. 

4.5.1 A Registration/erasure 

The OIP service requires no registration. Erasure is not applicable. 
The OIR service requires no registration. Erasure is not applicable. 

4.5.1 B Interrogation 

For interrogation of OIP and OIR, the mechanisms specified in subclause 4.5.0 should be used. 

4.5.2 Invocation and operation 
4.5.2.1 Actions at the originating UE 

As part of basic communication, the originating UE may insert a P-Preferred-Identity header field in any initial SIP 
request for a dialog or in any SIP request for a standalone transaction as a hint for creation of a public user identity as 
described in 3GPP TS 24.229 [3]. 

NOTE 1: According 3GPP TS 24.229 [3], the UE can include any of the following in the P-Preferred-Identity 
header field: 

a public user identity which has been registered by the user; 

a public user identity returned in a registration-state event package of a NOTIFY request as a result of an 
implicit registration that was not subsequently deregistered or has expired; or 

any other public user identity which the user has assumed by mechanisms outside the scope of 
3GPP TS 24.229 [3] to have a current registration. 

If the originating user wishes to override the default setting of "presentation not restricted" of the OIR service in 
temporary mode: 

The originating UE shall include an "anonymous" From header field. The convention for configuring an 
anonymous From header field described in RFC 3323 [6] and RFC 3325 [7] should be followed; i.e. From: 
"Anonymous" <sip:anonymous@anonymous.invalid>;tag= xxxxxxx. 

If only the P-Asserted-Identity needs to be restricted the originating UE shall include a Privacy header field set 
to "id" in accordance with RFC 3323 [6], and RFC 3325 [7]. 
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If all headers containing private information need to be restricted the originating UE shall include a Privacy 
header field set to "header" in accordance with RFC 3323 [6], and RFC 3325 [7]. 

If the originating user wishes to override the default setting of "presentation restricted" of the OIR service in temporary 
mode: 

The originating UE shall include a Privacy header field of privacy type "none" in accordance with 
3GPP TS 24.229 [3] (IETF RFC 3323 [6]). 

4.5.2.2 Void 

4.5.2.3 Void 

4.5.2.4 Actions at the AS serving the originating UE 

For an originating user that subscribes to the OIR service in "permanent mode", the AS shall insert a Privacy header 
field set to "id" or "header" based on the subscription option if the request does not include a Privacy header field that is 
set to the corresponding value. If the request includes a Privacy header field that is set to "none", the AS shall remove 
the "none" value from the Privacy header field. Additionally, based on operator policy, the AS shall either modify the 
From header field to remove the identification information, or add a Privacy header field set to "user". 

For an originating user that subscribes to the OIR service in "temporary mode" with default "restricted", if the request 
does not include a Privacy header field, or the request includes a Privacy header field that is not set to "none", the AS 
shall insert a Privacy header field set to "id" or "header" based on the subscription option. Additionally based on 
operator policy, the AS shall either modify the From header field to remove the identification information, or add a 
Privacy header field set to "user". 

NOTE: When the OIR service is used, the originating UE is supposed to already have removed identity 

information. However because this UE is not trusted, this is also done by the AS to ensure that this 
information is removed. 

For an originating user that subscribes to the OIR service in "temporary mode" with default "not restricted", if the 
request includes a Privacy header field is set to "id" or "header", based on operator policy, the AS shall either modify 
the From header field to remove the identification information or add a Privacy header field set to "user". As an 
originating network option, if the "no screening" special arrangement does not exist with the originating user, the AS 
may attempt to match the information in the From header with the set of registered public identities of the originating 
user. If a match is not found, the AS may set the From header to the SIP URI that includes the default public user 
identity. 

4.5.2.5 Void 

4.5.2.6 Void 

4.5.2.7 Void 

4.5.2.8 Void 

4.5.2.9 Actions at the AS serving the terminating UE 

If OIP service of the terminating user is not activated, then the AS shall remove any P-Asserted-Identity or Privacy 
header fields included in the request. Additionally, the Application Server may as a network option anonymize the 
contents of the From header by setting it to a default non significant value. As a network option, if the terminating user 
has an override category, the AS shall send the P-Asserted-Identity headers and remove the Privacy header fields. 

When the Privacy header field is set to "id", with the exception of the cases listed above, the AS should not remove this 
Privacy header entry. 

NOTE: The priv-value "id" in the Privacy header will be used by the terminating UE to distinguish the request of 
OIR by the originating user. 
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If the request includes the Privacy header field set to "header" the AS shall: 

a) anonymize the contents of all headers containing private information in accordance with IETF RFC 3323 [6] and 
IETF RFC 3325 [7]; and 

b) add a Privacy header field with the priv-value set to "id" if not already present in the request. 

If the request includes the Privacy header field set to "user" the AS shall remove or anonymize the contents of all "user 
configurable" headers in accordance with IETF RFC 3323 [6] and IETF RFC 3325 [7]. In the latter case, the AS may 
need to act as transparent back-to-back user agent as described in IETF RFC 3323 [6]. 

4.5.2.10 Void 

4.5.2.11 Void 

4.5.2.1 2 Actions at the terminating UE 

A terminating UE shall support the receipt of one or more P-Asserted-Identity header fields in SIP requests initiating a 
dialog or standalone transactions, each one containing a public user identity of the originating user. The UE may present 
the information to the user. 

NOTE 1 : If no P-Asserted-Identity header fields are present, but a Privacy header field was present, then the one or 
more identities can have been withheld due to presentation restriction. 

NOTE 2: If neither P-Asserted-Identity header fields nor a Privacy header field are present, then the 

network-provided identities can lack availability (due to, for example, interworking with other networks), 
or the user can be without a subscription to the OIP service. 

NOTE 3: A user -provided identity can also be available, within the From header field of the request 

4.6 Interaction with other services 

4.6.1 Communication Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.2 Terminating Identity Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.3 Terminating Identity Restriction (TIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.4 Originating Identity Presentation (OIP) 

The OIR service shall normally take precedence over the OIP service. 

The OIP service can take precedence over the OIR service when the destination subscriber has an override category. 
This is a national matter, and is outside the scope of the present document. 

4.6.5 Originating Identity Restriction (OIR) 

The OIR service shall normally take precedence over the OIP service. 

The OIP service can take precedence over the OIR service when the destination user has an override category. This is a 
national matter, and is outside the scope of the present document. 
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4.6.6 Conference calling (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.7 Communication diversion services (CDIV) 

When a request has been diverted and the diverted-to user has been provided with the DIP service, the diverted-to UE 
shall receive the identity information of the original originating user. When the OIR service has been invoked, the 
originating user's identity information shall not be presented to the diverted-to user unless the diverted-to user has an 
override category. 

4.6.8 Malicious Communication IDentification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

NOTE: When the MCID service is invoked, the identity of an incoming communication is registered in the 
network whether or not the originating user has activated the OIR service. 

4.6.9 Incoming Communication Barring (ICB) 

Within the network execution of ICB and ACR services shall precede the OIP service. 

4.6.1 Explicit Communication Transfer (ECT) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.7 Interactions with other networks 

4.7.1 Void 

4.7.2 Void 

4.7.3 Void 

4.8 Signalling flows 

No OIP or OIR service specific signalling flow is necessary in addition to the basic communication control according to 

3GPPTS 24.229 [3]. 

4.9 Parameter values (timers) 

No specific timers are required. 

4.10 Service configuration 
4.10.0 General 

Originating Identity documents are sub-trees of the simservs XML document specified in 3GPP TS 24.623 [13]. As 
such. Originating Identity documents use the XCAP application usage in 3GPP TS 24.623 [13]. 

Data semantics: The semantics of the Originating Identity XML configuration document is specified in 
subclause 4.10.1. 
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XML schema: Implementations in compliance with the present document shall implement the XML schema that 
minimally includes the XML Schema defined in subclause 4.10.2 and the simservs XML schema specified in 
subclause 6.3 of 3GPP TS 24.623 [13]. 

An instance of an Originating Identity document is shown: 

<?xml version="l . 0" encoding="UTF-8" ?> 

< simservs xmlns="http : //uri . etsi .org/ngn/params/xml/simservs/xcap" 

xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 

< originating- identity-presentation active="true"/> 

<originating- identity-presentation- restrict ion active="true" > 

<def ault- behaviour >present at ion- res trie ted< /default -behaviour > 
< /originating- identity-present at ion- res triction> 

</simservs> 



4.10.1 Data semantics 

The OIP service can be activated/deactivated using the active attribute of the <originating-identity-presentation> service 
element. 

The OIR service can be activated/deactivated using the active attribute of the 

<originating-identity-presentation-restriction> service element. Activating the OIR service this way activates the 
temporary mode OIR service. When deactivated and not overruled by operator settings, basic communication 
procedures apply. 

The behaviour of the temporary mode OIR is configured with the optional <default-behaviour> element. There are two 
values that this element can take: 

Presentation-restricted: This configures the service to behave as specified in subclause 4.5.2.4 for the case OIR 
service in "temporary mode" with default "restricted". 

Presentation-not-restricted: This configures the service to behave as specified in subclause 4.5.2.4 for the case 
OIR service in "temporary mode" with default "not restricted". 

Manipulation of the active attribute of the <originating-identity-presentation> service element and of the 
<originating-identity-presentation-restriction> service element is subject to authorization via local policy. Unauthorized 
manipulation attempts are rejected with an HTTP 409 (Conflict) response as defined in IETF RFC 4825 [16]. 



4.10.2 XML schema 



<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns : ss="http : //uri . etsi . org/ngn/params/xml/simservs/xcap" 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="http : //uri .etsi .org/ngn/params/xml/simservs/xcap" elementFormDef ault =" qualified" 

attributeFormDefault= "unqualified" > 

<xs : element name="originating-identity-presentation-restriction" 
substitutionGroup="ss : absService" > 
<xs : annotation> 

<xs :documentation>Originating Identity presentation Restriction 
</xs : documentation> 
</xs : annotation> 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="ss : simservType" > 
<xs : sequence> 

<xs : element name="def ault-behaviour" def ault="presentation-restricted" 
minOccurs= " " > 

<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value= "presentation- restricted" /> 
<xs : enumeration value="presentation-not- restricted" /> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
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</xs : complexContent> 
</xs : complexType> 
</xs : element > 

<xs : element name = " originating- identity-present at ion" type="ss : simservType" 
substitutionGroup="ss : absService" > 
<xs : annotation> 

<xs :documentation>Originating Identity Presentation 
</xs : documentation> 
</xs : annotation> 
</xs : element > 
</xs : schema> 
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Annex A (informative): 
Signalling flows 

No signalling flows are provided. 
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Annex B (informative): 
Example of filter criteria 



This annex provides an example of a filter criterion that triggers SIP requests that are subject to 
Initial Filter Criteria (IFC) evaluation. 



B.1 Originating filter criteria for OIR service 

All outgoing SIP requests are forwarded to an Application Server providing the OIR service under the following 
conditions: 

the user is subscribed to the OIR service in permanent mode; or 

the request does not include a Privacy header field. 



B.2 Terminating filter criteria for OIP service 

All incoming SIP requests are forwarded to an Application Server providing the OIP service. 
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